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Summary 

In this paper we describe the semantics of the programming language "COW." COW is a fun 
language developed within the Esoteric Programming Languages Ring, in which all keywords are 
some form of MOO. We present natural and structural operational semantics for the language. 
We also show that COW is Turing complete. 

Language Specification 

The following table contains all instructions available in COW, according to [Heber]. It is important 
to note that COW syntax does not enforce any particular instruction order. Instructions can be 
written in arbitrary order and still make a correct COW program. This has nasty consequences for 
loops, because loops consist of two instructions (moo and moo) that belong together. In the 
remainder of this text we discuss the problems that arise in the semantics and how they can be 
solved. 



Code 


Instruction 


Meaning 





moo 


This command is connected to the MOO command. When 
encountered during normal execution, it searches the program code 
in reverse looking for a matching MOO command and begins 
executing again starting from the found MOO command. When 
searching, it skips the instruction that is immediately before it (see 
MOO). 


1 


mOo 


Mo\/pq piirrpnt mpmnrv nnQitinn har*k nnp hlnpk 

iviuvco u u i i ci i l 1 1 1 ci 1 1 u i y uu o i li u i i Uuur\ u i i c kj i u ur\ . 


o 


moO 


iviuvco ourruni iiiuiiiury pubiuun iurwd.ru uric uiuok. 


3 


mOO 


Execute value in current memory block as if it were an instruction. 

Thp mmm^nrl pyppiitprl iq hpQprl nn thp instruction poHp vahip ^fnr 

1 IIC \s\J\ 1 1 1 1 1 Cll IU CACLiUlCU ID UuOCU W 1 1 11 IC 1 1 1 O LI U U LIU 1 1 UUUC V QlUC ^IUI 

example, if the current memory block contains a 2, then the moO 
command is executed). An invalid command exits the running 
program. Value 3 is invalid as it would cause an infinite loop. 


4 


Moo 


If current memory block has a in it, read a single ASCII character 
from STDIN and store it in the current memory block. If the current 
memory block is not 0, then print the ASCII character that 
corresponds to the value in the current memory block to STDOUT. 


5 


MOo 


Decrement current memory block value by 1. 


6 


MoO 


Increment current memory block value by 1 . 


7 


MOO 


If current memory block value is 0, skip next command and resume 
execution after the next matching moo command. If current memory 
block value is not 0, then continue with next command. 


8 


OOO 


Set current memory block value to 0. 


9 


MMM 


If no current value in register, copy current memory block value. If 
there is a value in the register, then paste that value into the current 
memory block and clear the register. 


10 


OOM 


Print value of current memory block to STDOUT as an integer. 


11 


oom 


Read an integer from STDIN and put it into the current memory 
block. 



Syntax 

The grammar of COW is specified as follows: 
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S ::= moo | mOo | moO | mOO | Moo | MOo | MoO | MOO | OOO | MMM | OOM | oom | Si S 2 . 

Here, S is short for statement. It is not necessary to separate statements from each other in a 
composition, since all COW statements have a length of precisely three characters so that a 
parser is able to determine where a statement begins and where it ends. 

Since moo and moo form a while-loop together, it seems logical to join them as one syntactical 
construction. Unfortunately, we cannot do so because the instruction moo can produce individual 
moos and moos, so that (half) while-loops can be formed dynamically. It is also possible for a 
program to end while still inside a while-loop! 

State 

We represent the state as a 6-tuple s = (M, p, r, V, W, I) where: 

• M is an infinite list m , ... with m, e Z, which represents the memory (data storage). At 
the start of program execution, this list is filled with zeros. 

• p e N is the memory pointer. It points to the active memory element m p e M. The memory 
points is initially and can never be negative.. 

• r e Z u e is the register (see the mmm instruction). The register is initially empty (e). 

• V is a finite list of input values v ,...,v n where Vi e Z, representing the input values that are 
given to the program using the keyboard (from STDIN). At the start of program execution the 
list contains zero or more elements (n > 0). 

• W is a finite list of output values w , w n where Wi e Z, representing the output values of 
the program (sent to STDOUT). The list W is initially empty (n = 0). 

• I is the nesting level, necessary for searching through while-loops (see natural semantics). At 
the start of program execution, the nesting level is 0. 

We choose to model input and output as part of the state, so that the semantics of a program with 
a given input (as a list of numbers) can be determined. Moreover, the input from stdln and 
output to stdout play an important role in COW. We want to be able to study the execution of a 
program by evaluating the final state of a program; this final state will contain the input and output 
lists after execution of the program has completed. 

Accessing the state 

Since the state is complex and not simply a function Var -» Z, like in the language While (see 
[Nielson92]), we must find a new method to access and modify the state. This method may 
consist of a number of functions with signature State -» State (actually comparable to the 
substitution operation used in [Nielson92]). 

In order to execute instructions in COW, we need access to all elements in the state, and not just 
the memory M. This means that we need a function for each type of modification. As an example, 
the function decrements the memory pointer by 1 : 

{(m,p-1,r,v,w,l) if p > 
(m,p,r,v,w,l) otherwise 

Of course, we can think of more convenient denotations: 

r s[p-»p-1] if P > 
"( s ) ~ i s otherwise 

This is possible because the functions generally work on only one part of the state. The 
definitions that increment, decrement or set the current memory block's value to zero, and the 
functions that add numbers to the output list or read numbers from the input list are trivial to 
construct. 
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We must be careful that no work is done in the function definitions that should be done in the 
specification of the natural semantics. We could have a function that evaluates the instruction 
Moo: 

4 Moo If current memory block has a in it, read a single ASCII character 
from STDIN and store it in the current memory block. If the current 
memory block is not 0, then print the ASCII character that 
corresponds to the value in the current memory block to STDOUT. 



This is possible because all the required information is stored in the state, but the effect of Moo 
can also be expressed in the rules for natural semantics, which is cleaner and more elegant. For 
this reason, we choose to define only very simple functions to modify the state. These functions 
will have no names. We will use the following intuitive syntax instead: 



<Moo, S> -> s[m p -> v , v -> tail(v)] als m p = 

One can imagine an s prefix, as in s.m p , so that the denotation resembles records in the Clean 
programming language. For operations on lists (arrays), we use the following simple operators 
taken from Clean: 



Function Meaning 



Example 



++ List concatenation 

head First element of a list 
tail List minus its first element 



[1,2] ++[3,4] -> [1 ,2,3,4] 
head [1,2,3] -> 1 
tail [1,2,3] -> [2,3] 



Natural Semantics 

The natural semantics of COW is easy to write, were it not for the instruction moo (3) which 
wrecks the day. Since we were unable to enforce complete while-loops in the syntax (but allow 
two halves instead), we have to deal with this problem in the natural semantics. 

Trivial instructions 

All instructions save 0, 3 and 7 are trivial to describe, and so is the composition of statements: 





[comp] 


<Si 


S 2 , s> ->s" 




1 


[mOo p>0 ] 


<mOo, s> 


-» s[p ->p- 1] 


if p > 


1 


[mOo p=0 ] 


<mOo, s> 


-» s 


if p = 


2 


[moO] 


<moO, s> 


^s[p ^p + 1] 




4 


[Moo in ] 


<Moo, s> 


-> s[m p -> v , v -> tail(v)] 


if m p = 


4 


[Moo out ] 


<Moo, s> 


s[v -> v + m p ] 


if m p it 


5 


[MOo] 


<MOo, s> 


-> s[m p -> m p - 1] 




6 


[MoO] 


<MoO, s> 


-> s[m p -> m p + 1] 




8 


[OOO] 


<000, s> 


-» s[m p -> 0] 




9 


[MMM] 


<MMM, s> 


-> s[r h> m p ] 


if r = e 


9 


[MMM] 


<MMM, s> 


-> s[m p -> r, r -> e] 


if r * e 


10 


[OOM] 


<OOM, s> 


-» s[w -> w ++ m p ] 




11 


[oom] 


<oom, s> 


-> s[m p -> v , v -> tail(v)] 
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Loop-instructies 

We have to do more work for instructions and 7 (moo and moo), because of the existence of half 
while-loops. We will solve this using an environment, in which we store the body of a while-loop. 
In fact, we store all the statements that follow moo (including moo itself). The environment env is a 
list of statements (initially empty). When a while-loop begins, the instruction moo places all the 
statements that follow it in the enviroment. The end of the loop, moo, retrieves all the statements 
from the environment and executes them, thereby execution the loop again. Since loops may be 
nested, it is necessary that the environment contains a list of statements. An example of an 
environment that contains the body of two nested loops is: 

env= [ [ MOO MOO OOO moo moo ], [ MOO 000 moo moo ] ] 

Note that the desired effect could have been achieved using continuations (see the semantics for 
break in [Nielson92]). Still, the use of continuations still requires a nesting flag (see below), so 
that the semantics will be equally complex. 

Loop execution 

If m p + 0, then all instructions following moo must be executed until the matching moo is found. 
Since we cannot look back in the code after finding a moo instruction, we must use an 
environment. Upon entry of the loop, we save all the statements that follow moo in the 
environment, and upon execution of moo we take them off again. This process can be executed 
with nesting, where multiple pieces of code are stored in the environment. 

push(MOO S, env) + <S, s> -» s' 

TTT^h, ; ifm D *0 

env + <M00 S, s> —■ s H 

P°P( env ) + <S, s > -> s where top(env) = S 

env + <moo, s> -» s' 

Access to the environment is provided using the functions push, pop and top, which are defined 
as follows: 



[M00 loop ] 
[moo loop ] 



push: S x env -> env = env ++ S 
pop: env -> env = tail(env) 
top: env -> S = head(env) 

The environment is a list of statement lists. The auxiliary functions ++, head and tail have 
definitions similiar to their definitions in the Clean language. 

Forward search 

According to the specification of moo, this instruction must skip all instructions that follow it (until 
the matching moo is found) when m p = 0. Note that when searching, we must always skip the 
instruction that directly following moo. 

In order to fulfill this last condition, we immediately replace moo with moo2 and skip the instruction 
immediately following moo. We use the composition of statements in the five natural semantics 
rules for moo below. To make sure that searching only stops when the matching moo is found 
(and not just a nested moo), we keep track of the nesting level in the state (as I). 

begin sea^ env + <M002 S 2 , S> -> S ' Q 

env+ <(MOOS 1 )S 2 , s> ^ s' P 
r. .^^search, env + <M002 S 2 , s> -» s' 

M00 searc 1 — — — - - ' ; Si * MOO & Si * moo 

env + <(M002 SO S 2 , s> ->s' 

[M00 begin nes ) env + <M002 S 2 , s[l -> I + 1]> -> s" 
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env + <(M002 MOO) S 2 , s> -*s' 
[MOO end nest ] env + <MOQ2 S 2 , s[l -> I - 1 ]> -» s' jf | > o 

env + <(M002 moo) S 2 , s> -» s' 

[MQO end searchj ^ + <(M qq 2 mQo) 3^ s> ^ s jf | = 

Example of a nested loop 

We determine the natural semantics of the following program, starting from a state where m p = 1 . 
The program consist of two nested loops, both of which must be executed exactly one (since 
m p = 1). 

MOO 

OOM \, outer 



MOO 
OOO 
moo 
moo 



} inner 
loop 



loop 



J 



[]+ <M002 moo, s>->s 

[] + <M002 moo, s[l->l- 1]>->S 

[ ] + <M002 moo moo, s> -» s 

[] + <M002 000 moo moo, s[l ->l +!]>-> s 

[outer] + <M002 moo moo, s> -> s [] + <M002 MOO 000 moo moo, s>->s 

[outer] + <M00 000 moo moo, s>-> s []+ <M00 OOM MOO 000 moo moo, s>->s 

[outerjnner] <moo, s>-> s [outer] <moo, s>-> s 

[outerjnner] <moo moo, s> -» s 
[outerjnner] + OOO, s>-> s[m?->0] 

[outer,inner:=[MOO 000 moo moo]] + <000 moo moo, s> -» s 

[outer] <M00 000 moo moo, s>-> s 

[outer] + OOM, s>-> s[w -> w ++ mp] 

[outer:=[MOO OOM MOO 000 moo moo]] + OOM MOO 000 moo moo, s>->s 

[] + <M00 OOM MOO 000 moo moo, s>->s 



Explanation 

The first moo in the program initiates a loop that will be executed. Immediately before execution, 
the loop body (i.e. the rest of the program) is stored in the environment and execution continues 
with the statement that follows moo. The next moo does the same thing (since m p is still 1) and 
the remainder of the program after the second moo is also placed in the environment. Execution 
continues. 

The first moo makes sure that the inner loop loops. It retrieves the code for the inner loop from the 
stack and executes it. At this point m p = 0, so that all instructions after moo are skipped until the 
matching moo is found, after which execution is resumed. The same thing happens for the last 
moo, but note that after a moo with m p = Q the instruction immediately following it is always 
skipped, until the matching moo is found. This means that we must keep track of the nesting level 
in the state (and we do just that in this example). 

Instruction generation 

The natural semantics described above still lacks the moo instruction, which executes a value 
from memory as if it were an instruction. With our loop definitions this works just right. The natural 
semantics of moo can de defined as a group of rules. There is no rule for m p = 3, since that would 
result in an infinite loop. 
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n <moo, s> — > s 

[mOO°] — ^ ; if m p = 

<mOO, s> —■ s 

r <mOo, s> ^ s' 

mOO : ifm p =1 

<mOO, s> -> s 

r ~~2, <moO, s> -> s' , 

mOO 2 - ifm p = 2 

<mOO, s> -» s' 

4 <Moo, s> -> s' 

[mOO 4 ] — ^ 1 if m p = 4 

<mOO, s> -» s 

r ~~5 n <MOO, S> -> S' . r 

mOO : if m p = 5 

<mOO, s> -> s' 

r ~~6, <MoO, s> -> s' ., 

mOO b : if m p = 6 

<mOO, s> -> s 

r ~~7, <MOO, s>^s' 

mOO — ^ ; if m p = 7 

L J <mOO, s> -> s' p 

r ~~8, <000, s> -> s' 

[mOO 8 ] — : ; if m p = 8 

<mOO, s> —■ s 

r ~~9n <MMM, S> ->S' 

mOO : if mp = 9 

<mOO, s> -» s' 

r ~~io, <OOM, s> -> s' 

mOO : ifm p = 10 

L 1 <mOO, s> -» s' P 

n <oom, s> -» s' 

[mOO 11 ] ■ if m p = 1 1 

<mOO, s> -> s' 
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Structural Operational Semantics 

As opposed to natural semantics (big-step semantics), structural operations (small-step 
semantics) describes how the first (smallest) step of the execution of a statement takes place. 

Trivial instructions 

The instructions that were trivial to specify in natural semantics (all instructions save 0, 3 and 7) 
are also trivial in structural operational semantics, since they consist of precisely one step. These 
instructions reduce to a final state right away. An exception is the composition of statements, 



which consists of two parts. 








fpnmn^ 1 

[UUIII[J J 


<Si, s> => <S'i, s'> if statement Si cannot be executed ine 




<Si S 2 , s> => <S'i S a s'> one step 






[comp 2 ] 


<Si 


, s> => s' If statement Si can be executed in one 




<Si S 2 , s> => <S 2 , s'> step 




1 


[mOo p=0 ] 


<mOo, s> 


=> s 


if p = 


2 


[moO] 


<moO, s> 


^s[p^p + 1] 




4 


[Moo in ] 


<Moo, s> 


=> s[m p -> v , v -> tail(v)] 


if m p = 


4 


[Moo out ] 


<Moo, s> 


=> s[v -> v + m p ] 


if m p ^ 


5 


[MOo] 


<MOo, s> 


=> s[m p -» m p - 1] 




6 


[MoO] 


<MoO, s> 


=> s[m p -> m p + 1] 




8 


[OOO] 


<000, s> 


=> s[m p -> 0] 




9 


[MMM] 


<MMM, s> 


=> s[r -> m p ] 


if r = e 


9 


[MMM] 


<MMM, s> 


=> s[m p -> r, r -> e] 


if r * e 


10 


[OOM] 


<00M, s> 


=> s[w -> w ++ m p ] 




11 


[oom] 


<oom, s> 


=> s[m p -> v , v -» tail(v)] 





Loop instructions 

Just like in natural semantics, in structural operational semantics we use an enviroment to store 
the bodies of while loops. Because of the existence of 'half while loops it was necessary to 
denote the natural semantics in a style which strongly resembles structural operational 
semantics, and it turns out that the denotation of the latter does not differ much from the former. 

Loop execution 

The rules for loop instructions are analogous to the natural semantics rules, the only difference 
being that we only rewrite the instructions, and do not describe an iteration's final state (i.e. there 
is no s'). 

[MOO loop ] env + <MOO S, s> => push(MOO S, env) + <S, s> ifm p *0 

[moo oop ] env + <moo, s> -» pop(env) + <S, s> where top(env) = S 

The functions push, pop and top that allow access to the environment are unchanged. 

Forward search 

The rules for forward search in a loop are also analogous to the rules in natural semantics. The 
structural operational semantics is easier to read because we search through the loop step -by- 
step (something we could only do in natural semantics by jumping through some hoops). 



9 



[M00 begin searchj env + <(M001 IS,] I S 2 , S> => if m p = 

L J env + <M002 S 2 , s> p 

r ..~. -.search, env + <(M002 S-|) S 2 , S> => „ mrsrs o o 

[M0 ° 1 env ! <M002 S 2 , s> * MOO & S 1 * moo 

rMnn begin nest, env + <(M002 MOO) S 2 , S> => 

L J env + <M002 S 2 , s[l -> I + 1]> 

end nes, env + <(M002 ! moo) S 2 , s> => 
L J env + <M002 S 2 , s[l -> I - 1]> 

[M0Q end searchj em + <{MQQ2 mQo) ^ s> ^ <s ^ s> if I = 



Instruction generation 

The rules for instruction generation with moo are the same as in natural semantics (we change h> 
to =>). We do not include them here. 

Comparison of semantics denotations 

Now that we have specified the natural and structural operational semantics of COW, we are in a 
position to consider the differences. The natural semantics is useful if we are able to define a 
relationship between the initial state and the final state of the execution of an instruction (like we 
can do in the H/Me-language [Nielson92]). In COW we were unable to do this for loops, due to 
the existence of 'half while loops: there is no guarantee that a moo (begin loop) is followed by a 
matching moo (end loop). In the structural operational semantics we only look ahead one step, 
resulting in more readable semantics. 
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Turing Completeness 

We still need to prove that the programming language COW is Turing complete. This can be 
proven in the following ways [Faase]: 

1) Show that there is a mapping from each possible Turing machine to a program in COW; 

2) Show that there is a COW program that simulates a universal Turing machine; 

3) Show that COW is equivalent to a language known to be Turing complete; 

4) Show that COW is able to compute all computable functions. 

Options 2 and 3 look to be very complex. Option one is interesting, but will result in a large COW 
program that will serve as proof. Since COW programs are hard to read, we do not think that this 
is a convenient proof to follow, but the approach is clear: if we can show that COW is able to 
search through a table structure in memory, read coded Turing machine transitions from it and 
execute them, then we proven most of what we need to prove. 

Computable functions 

We believe that option 4 gives us the most transparent proof. According to [Sudkamp98] the 
computable functions are: 

a) The functions 

- successor s: s(x) = x + 1 

- zero z: z(x) = 

- projection pj (n) : pj (n) (x-|...x n ) = x,, 1 < i < n 

b) Functions created through functional composition, i.e. 

f(xi x k ) = h( gi(x!,..., x k ), g 2 (x 1 ,..., x k ) ) 

The computability of f follows if g and h are computable. 

c) Functions created through primitive recursion. 

If g and h are computable (with n and n+2 arguments, respectively), then 

f (Xi,..., X n , 0) = g (Xi, X n ) 

f (X!,..., x n , y+1) = h (x,, x n , y, f (x 1: x n , y) ) 
is also computable. 

d) The function f created through minimalisation is also computable: 

f (Xi,..., X n ) = ^IZ [ p(X!,..., X n , z) ] 

if p is a computable predicate with n+1 arguments. Minimalisation yields the smallest z 
for which p(x-i,..., x n , z) is true (1). 

Proof structure 

We need to show that 

a) there is a function mechanism in COW; 

b) s, z and p exist in COW; 

c) functies in COW can be composed; 

d) a COW function can call itself recursively; 

e) minimalisatie can be implemented in COW (using recursion). 

If COW can do all of these things, then the language is Turing complete. 

Function mechanism 

We state that 

a) If COW is able to provide a function with its arguments, somewhere in memory (the 
'stack') and 
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b) some piece of code (the function) can use these arguments and replace its first argument 
with its result after execution 

then we have a function mechanism. The nice thing about this mechanism is that functional 
composition follows immediately from it: if the function g in fo g yields x, then this result is placed 
in the memory location where f expects its argument. 

We will say the a function call consists of a prelude, which sets up the arguments for use by a 
function f, and a postlude, which performs cleanup if necessary. 



PRE 




f 




POST 


¥■ 


1- 



The prelude does the following: 

• Moves the memory pointer to the memory area where the function arguments will be placed. 
This can be done using the instructions mOo and moo. 

• For each argument xf. 

o Let m[p] := x,-. This can be done with ooo and MoO. 

o If more arguments follow, the prelude increases the memory pointer by one (with 
moO). 

• Move the memory pointer back to the first argument. 

The memory contents from memory pointer p, after the prelude, looks like this: 



X2 



f 



The function body follows the prelude, and this code may assume that the memory pointer points 
to its first argument. The function knows how many arguments it has, and provides the code that 
retrieves the arguments. The function is responsible for replacing its first argument with its result. 
The result after execution of a function is therefore: 



R 


x 2 




X„ 



t 

p 

Here, R represents the function result. Note that the values x 2 ...x n are undefined. The function is 
free to change them. It might be better if R did not overwrite a function argument (cf. the C 
function call mechanism), so that the prelude would have to reserve space for R on the stack. 
However, the approach we use is sufficient for our purposes. 

The postlude has no work to do. With our mechanism, the code that follows fcan use the function 
result, even if this code is another function g (with one argument). We could have a postlude that 
sets all arguments used (except the result) to zero, but this is unnecessary. 
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Basic functions 

We show that the functions s, z and pj (n) exist in COW by defining them. 
The successor function is: 

s = MoO 
The zero function is: 

Z = 000 

The projection function is: 

Pi'"' = mod 1 MMM mOo A MMM 

Functional composition 

We define functional composition as: 

Let fbe the composition of a function ft: N n -> f^l with the functions g 1: g 2 , g n , all f^ k -> N. If all 
g t and h are computable, then fis also computable. 

In COW, such a construction looks like this (for the sample function h(g 1 (xi,x 2 ),g2(x 1 ,x 2 )): 





f: 


















PRE 






9i 




INTER 




92 




REWIND 




h 






POST 




> 


> 


> 































The prelude places the arguments for function g-i on the stack, so that the stack looks like this: 
(for the sample function): 



T 

p 

The function g 1 uses the arguments x 1 and x 2 , and places its result at position p. We now place 
an interlude between two function g, and g,, which increases the memory pointer p by 1 and 
places the arguments for function g s on the stack. The result of the interlude after g 1 in this 
example: 



Execution of g 2 yields: 



gi(xi,x 2 ) 


Xi 


x 2 




T 






p 




gi(xi,x2) 


g2(xi,x 2 ) 



t 



In order to execute h with the results of g 1 and g 2 we need the rewind element. This code moves 
the memory pointer back to the first result, i.e. the instruction mOo is executed n-1 times. After 
this, h can be executed directly with the arguments on the stack. So, rewind is the prelude of h. 

It follows from this example that functional composition is possible in COW. 



Primitive recursion 

COW does not have a function call mechanism. The only tool we have to implement recursion is 
the while loop. We can do this by evaluating the recursion bottom-up. 
Primitive recursion is defined as: 

f (Xi,..., X n , 0) = g (Xi, .... X n ) 

f (xi,..., x n , y+1) = h (xi, x n , y, f (xi, x n , y) ) 
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If we first compute g(x h %,), then apply the function h to the result (and a suitable y), and 
repeat the application of h as many times as necessary, then we achieve the desired result. Of 
course a recursion is always evaluated this way, but we make the order explicit in our proof, so 
that we can solve the recursion using a while loop. 

Diagrams are too complex for this implementation. We will illustrate the approach by showing the 
contents of the stack during the computation, where xis short for the vector x 1: x 2 , x n . 



x, y The prelude of f places xand yon the stack. 

x, y, g(x) g(x) is evaluated. This is the basis for the recursion. A 

postlude makes sure that the result of g(x) is stored on 
the stack just after the arguments xand y. 

x, y = 1 , g(x), c Now, let c := y, and y := 1. The counter c keeps track of 

the number of recursion iterations we must still execute. 
Since the counter decrements (rather than increments), 
we can use a while loop. 

x, 1 , h(x,1 ,g(x)) c-1 We execute h with parameters x, y and g(x). Here, g(x) is 

the value of ffor fx, y-1). 

x, 2, h(x,2,h(x,1 ,g(x))) c-2 We execute h with parameters x, y and h(x,2,f), where f 

represents the previous value of the recursion. 

x, 3, h(x,3,h(x,2,h(x,1 ,g(x)))) c-3 We execute h with parameters x, yand h(x,3,f), where f 

represents the previous value of the recursion. 

h(x, y, f(x, y)) When the counter c reaches 0, the recursion ends. This 

means that in our implementation, the while loop is not 
repeated anymore. A postlude makes sure that the result 
h(x,y,f(x,y)) is stored on the first stack position, so that it 
may be available for a next function in a functional 
composition. 



In order to evaluate the computation suggested by this stack trace, COW must be able to 

• Copy function arguments; 

• Move function arguments; 

• Execute a while loop. 

COW has instructions to perform these operations (as already shown in the discussions on the 
function mechanism and functional composition), so that primitive recursion can be implemented 
in COW. 



Minimalisation 

Minimalisation also uses recursion, but the solution is simpler in this case. We make use of a 
stack trace to illustrate minimalisation: 



The prelude of function f places xon the stack. 



1 , x The termination condition of the minimalisation (is there a 

suitable z yet?) is initially untrue. We represent this as 1, 
since this value is used to decide whether the while loop 
should be executed again. 

1 , 0, x, We start with z = 0. A copy of z is placed on the second 

stack position (and also behind x). 

1, 0, p(x, 0) = The predicate p is evaluated with arguments x and z. 

Suppose it yields 0. 

1, 0, p(x, 0) = The result is copied to the first stack position, and then 
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inverted. 

1 , 1 , x, 1 The while loop repeats, z is incremented by 1 and placed 

on the stack. We needed the copy of z to determine 
previous value. 

1,1, p(x, 1) = 1 The predicate p is evaluated with arguments x and z. 

Suppose it yields 1. 

0, 1 , p(x, 1 ) = 1 The result is copied to the first stack position, then 

inverted. The while loop now terminatesm because the 
termination condition (the first stack position) is now 0. 

1, ... The current value of z is copied to the first stack position 

and represents the result of the minimalisation. 



It follows that we can realize minimalisation in COW using a while loop. 



Result 

We have shown that COW has a function mechanism, with which we can implement the 
successor function, the zero function, the projecion function, functional composition, primitive 
recursion and minimalisation. From this we may deduce that COW is Turing complete. 
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